准备陆续把之前写下的阅读和学习笔记搬到博客上,这是其中之一。

欢迎批评。

第一章:可靠性、可维护性、可扩展性

1.数据密集型应用的标准组件

  • 数据库(database):存储数据
  • 缓存(cache):记住开销昂贵的操作,以加快读取速度
  • 搜索索引(search indexes):允许用户按关键字搜索数据,或过滤数据
  • 流处理(stream processing):向其他进程发送消息,进行异步处理
  • 批处理(batch processing):定期处理积累的大批量数据

2. 可靠性

- 硬件故障

硬件故障让人想到硬盘崩溃、内存出错、机房断电。

硬件冗余是一种增加容错率解决方案,例如由硬盘组成的 RAID、双路电源、热插拔 CPU 等。

- 软件错误

比起硬件故障,系统性错误往往是牵一发而动全身,例如级联错误。

- 人为错误

3. 可扩展性

- 描述负载的参数

扇出描述用来在事务处理系统中为了服务一个传入请求而需要执行其他服务的请求数量。

在推特的例子中,每个用户粉丝数的分布(可能按这些用户的发推频率来加权)是探讨可扩展性的一个关键负载参数,因为它决定了扇出负载。

推特逐步转向了两种方法的混合。大多数用户发的推文会被扇出写入其粉丝主页时间线缓存中。但是少数拥有海量粉丝的用户(即名流)会被排除在外。当用户读取主页时间线时,分别地获取出该用户所关注的每位名流的推文,再与用户的主页时间线缓存合并。
当负载被描述好,就可以研究当负载增加时会发生什么。

- 描述性能的指标

性能指标:

  • 吞吐量
  • 平均响应时间
  • 百分点位

平均响应时间在很多场景是没有意义的。

百分位点通常用于服务级别目标(SLO, service level objectives)和服务级别协议(SLA,service level agreements),即定义服务预期性能和可用性的合同。 SLA 可能会声明,如果服务响应时间的中位数小于200毫秒,且99.9百分位点低于1秒,则认为服务工作正常(如果响应时间更长,就认为服务不达标)。这些指标为客户设定了期望值,并允许客户在 SLA 未达标的情况下要求退款。

- 应对负载的方法

纵向扩展(垂直扩展)
横向扩展(水平扩展)

弹性系统 VS. 手动扩展

  • 当负载极难预测时,弹性系统比手工扩展更有用。
  • 手工扩展系统更简单,并且意外操作更少。

一个良好适配应用的可扩展架构,是围绕着假设(assumption)建立的:哪些操作是常见的?哪些操作是罕见的?这就是所谓负载参数。

4. 可维护性

软件系统设计原则

  • 可操作性
  • 简单性: 管理复杂度
  • 可演化性